PROGRAM AND METHOD FOR SUPPORTING INQUIRIES 
FROM SERVER TO OPERATOR 

BACKGROUND OF THE INVENTION 
5 1. Field of the Invention 

The present invention relates to a program and 
method for helping service processes in a server to 
receive information from other stations. More particularly, 
the present invention pertains to an inquiry support 
10 program and method that support a process of issuing 
inquiries from service processes and receiving replies 
from an operator. 

2 ■ Description of the Related Art 

Client-server systems are widely used today. 

15 Server programs running on a server computer (or simply 
"server") provide various services to a plurality of 
client computers (or simply "clients") in response to 
their demands. Generally, server programs are designed to 
offer a requested service according to a predetermined 

20 sequence of processing steps. Servers are supposed to 
continue their services, performing most tasks without 
operator intervention . 

The exception is that server programs sometimes 
need to be reconfigured, even in the middle of operation, 

25 to ensure the reliability of service. For example, a 
server program may encounter such a situation where it 
needs an instruction from the system operator before 
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proceeding to the next stage of service. Based on the 
operation Instruction, the server program decides which 
way to go. In this situation, the ongoing process on the 
server has to actively Interact with the operator console, 
5 displaying messages and prompting the operator to answer. 
The Interaction between a server and operator requires a 
set of user Interface functions, but It Is generally 
Impractical to Install such modules In each server program. 
Conventional servers therefore provide a mechanism for a 
10 server program to communicate with the operator, which Is 
a macro Instruction known as "wrlte-to-operator with reply 
(WTOR) . " 

FIG. 25 shows the concept of how WTOR macro 
Instructions work In a conventional client-server system. 

15 The Illustrated system Involves a server 910 and an 
operator console 920 connected to It. Actually, one or 
more processes or tasks are running on the server 910 to 
offer Intended functions or services. In this description 
we will refer to those server processes or tasks as 

20 "service processes." 

Referring to the system of FIG. 25, the server 910 
has an active service process 911 and a message display 
processor 912 as part of Its processing modules . The 
service process 911 provides functions described in a 

25 server program. The message display processor 912 sends 

WTOR messages to the operator console 920 when the server 

I. 

program uses WTOR macro ±nstruct:lons . The operator console 
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920, on the otJier hand, has a user interface controller 
921 to display messages sent from the server 910 and 
deliver console input such as keyboard data to the server 
910. 

5 When it needs an instruction from the operator, 

the service process 911 issues a WTOR macro instruction, 
attaching a piece of message text as a parameter. The 
service process 911 suspends its main service task until 
it receives a response to the WTOR macro instruction it 

10 has issued. The message display processor 912 assigns a 
message identifier for this WTOR macro instruction and 
sends an inquiry message with that message identifier to 
the operator console 920 . 

On the operator console 920, the user interface 

15 controller 921 displays the delivered message text and its 
corresponding message identifier on a monitor screen. The 
operator checks the message on the screen and then enters 
an answer to the operator console 920, as well as typing 
the message identifier, using the keyboard and other input 

20 devices. The operator console 920 sends the entered reply 
data to the server 910 . 

In the server 910, the received reply message is 
directed to the service process 911, which originated the 
WTOR macro instruction. Now that an operator input is 

25 obtained, the service process 911 resumes its task 
according to what the operator has instructed. For more 
details about this WTOR mechanism, refer to, for example. 
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"OSIV/MSP System Programming Manual (Task Management:) for 
AFII VIO OS IV/MSP," Fourth Edition, Fujitsu LIMITED, June, 
2000 (original in Japanese) . Particularly relevant are: 
Chapter 14, "Opera tor -Program Communications" and Section 
5 14.1.5, "Functions of WTOR Macro instruction." 

One drawback of the conventional method using a 
WTOR macro is that the operator is likely to make a 
mistake in writing an answer. That is, server programs 
expect the operator to enter a character string in a 

10 predefine format that they require, which, however, can 
easily be violated due to the respondent ' s simple typing 
errors . Such a formal error on the operator ' s part makes 
it impossible for the service process 911 to proceed with 
the next step because it is unable to parse the given 

15 reply. Suppose, for example, that the operator has entered 
an incorrect message identifier. This error causes the 
reply message to be delivered not to the intended service 
process 911, but to some other service process, thus 
disrupting the computing task that the service process 911 

20 is pursuing. 

Conventional server programs could encounter 
similar difficulties when the operator's answer has a 
syntactical error, which would confuse the service process 
911 in analyzing the message. Think of, for example, an 

25 inquiry as to whether some event has happened or not. 
Possible answers may be "yes"/"no" or "true"/ "false" or 
something else. Even for a simple question like this. 
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there is more than one way to answer. The answer cannot be 
parsed if it is not written in the way intended by the 
requesting service process 911. 

Once having issued an inquiry, the requesting 
5 service process has to wait until an answer is returned in 
a correct way. But staying too long in such a state is 
wasting precious computer resources (e.g., memory and disk 
space) . Besides slowing down the server 910, the presence 
of locked service processes could invite other serious 
10 problems in the operations of the server 910. 

SUMMARY OF THE INVENTION 
In view of the foregoing, the present invention 
discloses an inquiry support program and method that 

15 prevent an operator from returning a wrong reply in 
response to an inquiry message from a server. 

In one aspect of the present invention, a program 
product that helps service processes receive instructions 
from an operator is provided. This program product causes 

20 a computer system to perform a process comprising the 
following steps: (a) storing an inquiry to the operator in 
an inquiry buffer, upon issuance thereof from a service 
process; (b) retrieving the inquiry pending in the inquiry 
buffer and sending the retrieved inquiry to the first 

25 client over a network, in response to a first delivery 
request from a first client; (c) forwarding a reply 
received from the first client to the service process, as 



-5- 



well as storing the recexved reply and corresponding 
inquiry as a log record in a log memory; and (d) 
retrieving log records from the log memory and sending the 
retrieved log records to a second client on the network, 
5 in response to a second delivery request from the second 
client . 

In another aspect of the present invention, a 
method that helps service processes receive instructions 
from an operator is provided. This method comprises the 

10 following steps: (a) storing an inquiry to the operator in 
an inquiry buffer, upon issuance thereof from a service 
process; (b) retrieving the inquiry pending in the inquiry 
buffer and sending the retrieved inquiry to the first 
client over a network, in response to a first delivery 

15 request from a first client; (c) forwarding a reply 
received from the first client to the service process, as 
well as storing the received reply and corresponding 
inquiry as a log record in a log memory; and (d) 
retrieving log records from the log memory and sending the 

20 retrieved log records to a second client on the network, 
in response to a second delivery request from the second 
client. 

The above and other objects, features and 
advantages of the present invention will become apparent 
25 from the following description when taken in conjunction 
with the accompanying drawings which illustrate preferred 
embodiments of the present invention by way of example. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



FIG. 1 shows the concept of a method in which the 
present Invention Is embodied. 
5 FIG. 2 shows an example of a network system 

according to the present embodiment. 

FIG. 3 shows an example of a computer hardware 
platform on which the present Invention Is embodied. 

FIG. 4 Is a block diagram which shows the 
10 functional structure of a client-server system according 
to the present embodiment. 

FIG. 5 shows an example of an Inquiry message 
listing screen. 

FIG. 6 shows an example of a log listing screen. 
15 FIG. 7 shows an example of a reply log listing 

screen . 

FIG. 8 Is a sequence diagram showing how log 
records are displayed. 

FIG. 9 explains a concept of how the operator 
20 chooses an answer from a list of possible answers. 

FIG. 10 shows an example of a reply dialog box 
with an answer list. 

FIG. 11 shows an exeunple of a reply dialog box for 
free text Input. 

25 FIG. 12 Is a sequence diagram which shows a 

procedure of multiple-choice selection. 

FIG. 13 Is a conceptual view of a process that 
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produces a reply message by select:ing one of the reply log 
records . 

FIG. 14 shows an example of a reply log listing 

screen . 

5 FIG. 15 is a functional block diagram of a server 

with timeout processing functions. 

FIG. 16 shows an example of a timeout period table. 
FIG. 17 shows an example of timeout processing 
using a timeout period table. 
10 FIG. 18 is a sequence diagram showing a procedure 

of timeout processing. 

FIG. 19 shows an example of data structure of an 
inquiry buffer. 

FIG. 20 shows a specific example of data stored in 
15 the inquiry buffer. 

FIG. 21 shows an example of data structure of a 
log memory. 

FIG. 22 shows a specific example of data stored in 
the log memory. 

20 FIG. 23 is a conceptual view of a process which 

executes a command according to a given reply. 

FIG. 24 is a sequence diagram of a process that 
dispatches a command according to a given reply. 

FIG. 25 shows the concept of how ^OR macro 
25 instructions work in a conventional client-server system. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 
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Preferred einbodlmeni:s of the present: invention 
will be described below with reference to the accompanying 
drawings, wherein like reference numerals refer to like 
elements throughout. The following description will first 
5 outline the invention and then give a more specific 
explanation for how the invention will be implemented. 

FIG. 1 shows the concept of an inquiry support 
program in which the present invention is embodied. The 
inquiry support program of the present invention is 

10 intended for aiding a service process la to receive a 
reply to an inquiry that it sent to the operator. The 
service process la is part of a computer system that 
offers data processing and other services . This computer 
system, called a server 1, executes the inquiry support 

15 program of the invention, thereby functioning as an 
inquiry handler lb. More specifically, the inquiry handler 
lb executes the tasks described below. 

The service process la sometimes needs information 
from or intervention by the operator in the course of a 

20 specific service. When such an event happens, the service 
process la issues an inquiry 5 to the operator and stops 
execution of the service. Upon receipt of the inquiry 5 
from the service process la, the inquiry handler lb saves 
it in an inquiry buffer Ic (step si) . After that, in 

25 response to a request from the first client 3 that 
requires delivery of pending inquiries, the inquiry 
handler lb retrieves the inquiry 5 in the inquiry buffer 
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Ic and sends it to the first client 3 over the network 2 
(step s2) . 

The operator using a first client 3 gives an input 
in response to the received inquiry 5, and the first 
5 client 3 sends it to the server 1 as a reply 6 to the 
inquiry 5. Upon receipt of the reply 6 from the first 
client 3, the inquiry handler lb stores the original 
inquiry 5 and received reply 6 in a log memory Id in an 
associative way, as well as passing the reply 6 to the 
10 requesting service process la (step S3) . The information 
in this log memory Id is referred to as log records. With 
the reply 6 received, the service process la resiimes the 
service task that has been suspended since the issuance of 
the inquiry 5 . 

15 FIG. I shows another client on the same network 2. 

This second client 4 requests the server 1 to deliver log 
records, which causes the inquiry handler lb to retrieve 
relevant log records from the log memory Id and sends them 
back to the requesting second client 4 (step S4) . Upon 

20 receipt of those log records, the second client 4 produces 
a log listing screen 4a to show the log records of 
inquiries and replies . 

The above inquiry support program, when executed 
on a computer platform, stores log records including past 

25 inquiries and their corresponding replies. When a delivery 
request for such log records is received, the server 1 
sends stored log records to the second client 4 , allowing 
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"the operator of the second client 4 to browse them on a 
log listing screen 4a and learn how they were answered In 
the past similar cases . Records of such past replies help 
the operator write an answer to the present enquiry. That 
5 Is, he/she can reply to the present Inquliry more easily 
and correctly by following the way the past Inquiries were 
answered. The Inqpilry support program thus reduces the 
chance for him/her to use a wrong format or make other 
mistakes when answering an Incjulry. 

10 The first client 3 may receive a plurality of 

Inquiries at a time. If this Is the case, the first client 
3 displays a list of those Inquiries on a monitor screen, 
which allows the operator to choose one of them and write 
a reply 6 to it. The first client 3 never requires the 

15 operator to retype the identifier of an inquiry to select 
it, thus preventing him/her from making a mistake such as 
entering a wrong number. 

While FIG. 1 Illustrates the first and second 
clients 3 and 4 as separate units, the present invention 

20 is not restricted to that specific arrangement. The 
functions of those two clients 3 and 4 may actually be 
implemented on a single client computer. 

According to the present Invention, the incjulry 
handler lb shown in FIG. 1 has all or part of the 

25 following functions: 

(a) When the second client 4 requires delivery of log 
records , specifying particular search conditions , 
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the inquiry handler lb retrieves and sends such log 
records that match with the specified conditions. 
This function enables the second client 4 to display, 
for example, a list of log records of such inquiries 
5 that were answered during a particular period. 

(b) When the second client 4 requires delivery of 
message log records, the inquiry handler lb 
retrieves sends records including inquiry-related 
information (e.g., message, date). This feature 

10 enables the operator using the second client 4 to 

browse the records of past inquiries for reference 
purposes . 

(c) When the second client 4 requires delivery of 
reply log records, the inquiry handler lb retrieves 

15 and sends records including reply-related 

information to the requesting client 4. This 
function is helpful for the operator in the case 
he/she already has a particular inquiry of interest 
and wishes to see, for reference purposes, past 

20 replies that were made to similar inquiries. 

(d) ; When the second client 4 requires delivery of 

reply log records concerning a specific inquiry, the 
inquiry handler lb retrieves log records of similar 
inquiries (e.g. , those having the same message text) 
25 and provides the information cdDOUt what replies were 

made to those past inquiries . This function permits 
the operator using the second client 4 to 
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selectively browse the records of replies made to 
past similar inquiries. 

When delivering a pending inquiry to the first 
client 3, the inquiry handler lb may add an answer 
list to that inquiry. More specifically, each 
inquiry has a reply method identifier, and in the 
case that the identifier indicates that a multiple- 
choice selection should be made, the inquiry handler 
lb attaches a list of possible answers to the 
inquiry, thus causing the first client 3 to display 
two or more choices of answers on a monitor screen. 
The operator selects one answer from among those in 
the on-screen list, and it is returned to the 
requesting server 1. This function enables the 
operator using the first client 3 to give an 
appropriate answer by selecting one of predefined 
choices, with little possibility of making a mistake 
in answering the inquiry. 

When delivering a pending inquiry to the first 
client 3, the inquiry handler lb may retrieve log 
records of similar inquiries and sends the replies 
made to those past inquiries, together with the 
pending inquiry. This function permits the operator 
using the first client 3 to consult the records of 
past replies, thus reducing the chance of making a 
mistake in answering the present inquiry. 

If there is no reply within a predetermined 
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'bimeout period, t:he Inquiry handler lb no-blfles -bhe 
requesting service process la of -bhe cancellatilon of 
Its pending Inquiry. This function prevents the 
service process la from wasting too much time In 
expectation of receiving a reply. 

The Inquiry handler lb can use a timeout period 
specified In an Inquiry Itself. Expiration time of 
an Inc^lry Is calculated by adding the specified 
timeout period to the Inquiry's Issuance time. If 
this expiration time Is reached before an answer 
returns , the Inquiry handler lb notifies the 
requesting service process la of the cancellation of 
Its pending Inquiry. Thus the service process la has 
only to add a timeout period parameter to an Inquiry 
when Issuing It. With this feature, programmers can 
develop service processes more easily. 

Timeout period may be specified Indirectly by 
using timeout period Identifiers of Inquiries, and 
In. this case, the Inquiry handler lb calculates an 
expiration time with reference to a predefined 
timeout period table that associates a plurality of 
timeout period Identifiers with corresponding 
timeout period values. Besides allowing the service 
process la to vary the timeout period from Inquiry 
to Inqulary, this function permits the inquiry 
handler lb to give a specific time length to each 
group of inquiries having a particular timeout 



period identifier. Timeout: periods can thus be set 
dynamically in accordance with variations in the 
processing load of the server 1 or other parameters 
affecting the system environment. 
5 (j) A command may previously be associated with a 

pending inquiry so that a particular processing, task 
related to the inquiry will be executed 
automatically. The inquiry handler lb dispatches 
such a command, if any, upon receipt of a reply from 
10 the first client 3. Besides resuming a pending 

service process la, this feature makes it possible 
to invoke various post- inquiry tasks, such as 
sending an email message to the system administrator 
to inform him/her of the reply. 
15 (k) When dispatching a post-in<piiry command, the 

inquiry handler lb may add the received reply as a 
parameter of the command to be dispatched. This 
feature is used in, for example, creating an email 
message that informs someone of the reply. 
2 0 The above functions of the inquiry handler lb are 
implemented in the embodiments of the present invention as 
will be described in dietail in the following sections. 

FX6. 2 shows an example of a network system 
according to the present embodiment. A server 100 is 
25 connected to a plurality of clients 210 and 220 on a 
network 10 . 

FIG. 3 shows an example of a computer hardware 
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platform on which i:he present invention Is Implemented. 
The Illustrated server 100 has the following circuit 
elements: a central processing, unit (CPU) 101, a random 
access memory (RAM) 102, a hard disk drive (HDD) 103, a 
5 graphics processor 104, an Input device Interface 105, and 
a communication Interface 106. The CPU 101 controls the 
entire system of the server 100, Interacting with other 
elements via a common bus 107 . The RAM 102 temporarily 
stores the whole or part of operating system (OS) programs 

10 and application programs that the CPU 101 executes. In 
addition to other various data objects manipulated at 
runtime. The HDD 103 stores program and data files of the 
operating system and various applications. 

The graphics processor 104 produces video Images 

15 In accordance with drawing commands from the CPU 101 and 
displays them on the screen of an external monitor 11 
coupled thereto. The Input device Interface 105 Is used to 
receive signals from external Input devices, such as a 
keyboard 12: and a mouse 13 . Input signals are supplied to 

2 0 the CPU 101 via the bus 107. The communication Interface 
106 is connected to a network 10, allowing the CPU 101 to 
exchange data with other computers (not shown) on Uie 
network 10:. j 

The functions of the present Invention can be 

25 embodied with the above-described hardware structure . 
While FIG. 3 Illustrates a typical platform for the server 
100, the same or similar hardware structure may also be 
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applied to t:he clients 210 and 220. 

FIG. 4 is a block diagram which shows the 
functional structure of a client-server system according, 
to the present embodiment. In this system of FIG. 4, the 
5 operator uses a first client 210 to respond to inquiries 
and a second client 220 to browse various log records. The 
server 100 has, among others, a service process 110 and an 
inquiry handler 120. The inquiry handler 120 has an 
inquiry receiver 121, an inquiry buffer 122, an inquiry 

10 message sender 123, a reply message receiver 124, a 
message log sender 125, and a reply log sender 126. A log 
memozry 300 is connected to the server 100 . 

The service process 110 is actually one of the 
processing functions that the server 100 (server computer) 

15 provides through it& execution of a server program. More 
precisely, the service process 110 refers to a collection 
of one or more processes (tasks) that constitutes the 
server program. In normal: operation, the service process 
110 provides a service in response to a request from: the 

20 clients 210 and 220, as: well asi from, ot^er clients not 
shovm in FIG. 4*. The service process 110 may also be 
called up by the operating system and provide the. 
requested service to it. If it encounters a predefined 
event that needs operator intervention, the service^ 

25 process 110 suspends the current process and sends an 
inquiry to the operator. Suppose, for example, that the 
service process 110 needs an instruction from the operator. 
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Then 'the servxce process 110 produces a piece of 'tex'b 
(message -bex-t) -that: is intended for display on a client 
screen and invokes an inquiry API call including, the 
message as a parameter, where API stands for "application 
5 program interface." When a reply to this inquiry is 
returned, the service process 110 resumes the pending 
process with an appropriate procedure according to the 
reply . 

Message text, sent as a parameter of an inquiry 
10 API call, indicates what and how the operator is supposed 
to respond. The message says, for example, "Who is the 
contact person?" or "Select the place you are visiting for 
business . " 

The inquiry handler 120 helps the service process 
15 110 obtain a reply from the operator. The following, will 
describe tii& function of each element of the inquiry 
handler 120. 

The inquiry receiver 121 receives an inquiry API 
call from the service process 110. The inquiry receiver 

2 0 121 then stores the inquiry (i.e., the information 
contained in the received inquiry API call) in the inquiry 
buffer 122 . The inquiry buffer 122 , serving here as 
temporary storage for such inquiry information, may be^ 
implemented as, for example, a part of memory space of -Uie 

25 RAM 102 shown in FIG. 3. 

When so requested by the first client 210, the 
inquiry message sender 123 retrieves each inquiry pending. 



-18- 



±n -the Inquiry buffer 122 and produces an inquiry message 
based on tha^ information. The inquiry message sender 123 
then sends the produced inquiry message to the first 
client 210. 

5 The reply message receiver 124 receives a reply 

from the first client 210. The reply message receiver 124 
saves a log record concerning this inquiry session in the 
log memory 300, as well as passing the received reply to 
the requesting service process 110 . Each log record in the 

10 log memory 300 consists of several pieces of information, 
including those about an inquiry and those about a reply. 
The inquiry-related log information (e.g. , message text, 
transmission date of inquiry message) is referred to as 
"message log records . " On the other hand, the reply- 

15 related log information (e.g. , reply data, reception date 
of reply message) is referred to as "reply log records." 
The message log sender 125 reads message log records out 
of the log memory 300 and sends them to the second client 
220 when so requested by the. second client 220. Similarly, 

20 the reply log sender 126 reads reply log records out of 
the: log memory 300 for delivery to the second client 220 
when so requested by the second client 220. 

The first client 210 has a reply entry manager 2:11. 
The reply entry manager 211 is a user interface that 

25 displays received inquiry messages on the: monitor screen 
and accepts console input from the respondent who answers 
inquiries. More specifically, with the inquiry messages 
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received from the server 100, the reply entry manager 211 
produces an inquiry message listing screen to display the 
content of those inquiry messages. Also, when a reply is- 
entered by the operator, the reply entry manager 211 sends 
5 it to the server 100 as a response to one of the received 
inquiry messages . 

The second client 220 has a log display processor 
221, which is a user interface that requests, in response 
to console input from the operator, the server 100 to 

10 deliver log records. The request may be for either message 
log records: or reply log records or both. Upon receipt of 
such log records from the^ server 100, the log. display 
processor 221 produces a reply log screen to display the 
content of the received records . 

15 The log memory 300 is a storage medium to keep log 

records of transmitted inquiiry messages and their 
corresponding replies . Specifically, a part of the HDD 103 
shown in FIG-. 3 may be allocated for use as^ the log memory 
300 . 

20 The system illustrated in FIG. 4' operartes as; 

follows;. It is supposed here that the service process 110 
in. the server 100 is callled up to provide a client with 
processing services as requested. In normal operation, the 
service process: 110 is responsive to requests from the 

25 clients 210 and 220 shown in FIG. 4, as well as from those 
not shown in FIG. 4. When it encounters an event that 
needs an instruction from the operator, the service 



-20- 



process 110 produces a piece of message tex-b tihai: is: 
int:ended for display on a client screen and invokes an. 
inquiry API call including the message text as a parameter . 
The issuance of this API call causes the inquiry receiver 
5 121 to extract its parameters such as message text for 
inquiry and puts them into the inquiry buffer 122 . 

The reply entry manager 211 running on the first 
client 210 sends a delivery request to the inquiry message 
sender 123 over the network, thus collecting inquiry 

10 messages. In response to this delivery request from the 
reply entry manager 211,, the inquiry message sender 123 
retrieves pending inquiries out of the inquiry buffer 122 . 
The inquiry message: sender 123 then compiles inquiry 
messages from the obtained data and sends them to the 

15 reply entry manager 211 in the: first client 210. 

The reply entry manager 211 produces an inquiry 
message listing screen to display all the^ inquiry messages 
received from the inqpiiry message sender 123. From among 
those displayed in. the inquiry message listing screen, the 

20 operator chooses: one: message that he/she is going to 
respond to and enters reply data for that inquiry. This 
operator input enables the reply entry manager 211 to 
respond to the selected, inquiry message by sending the 
entered reply data to the reply message receiver 124. 

25 Upon receipt of the reply message from the client 

210, the reply message receiver 124 hands it over to the 
service process 110, and at the same time, it saves a log 
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record ±n the log memory 300, which Includes message text, 
reply data, reply date, and other related Items. 

On the second client 220, the log display 
processor 221 requests, through a network, the message log 
5 sender 125 to deliver message log records. The message log 
sender 125 In the server 100 then retrieves log records 
(message text, reply data, reply date, and other related 
Information) out of the log memory 300. The message log 
sender 125 selectively delivers message log records to the 

10 log display processor 221, extracting Inquiry message text 
and' the^ like from the retrieved log records. This causes 
the log display processor 221 to display a reply log 
screen- on the monitor of the second client 220, which 
shows the content of message log records. 

15 The operator at the second client 220 selects one 

of: the message log records displayed in the reply log 
screen and requests reply log records concerning the past 
inquiiry that he/she has selected. The log display 
processor 221 passes this request to the reply log sender 

2 0 12:6: over the network, transmitting a delivery request for 
reply log records that are relevant to the selected 
message log record. 

In the server 100, the reply log sender 126: 
searches the log memory 300 for log recordsr that include 

25 the same message text as the selected message log record.. 
The reply log sender 126 then returns a reply log record 
of each found log record to the log display processor 221. 



-22- 



The log display processor 221 displays a list: of received 
reply log records in the reply log record screen, which 
indicates what response was xaade to each past inquiry 
message. 

5 FIG. ' 5 shows an example of an inquiry message 

listing screen. The illustrated inquiry message listing 
screen 30 has an a plurality of command buttons 31a to 31f 
and an inquiry message listing pane 30a. The command 
buttons 31a to 31f are used to initiate a particular 

10 action to handle inquiry messages displayed on the inquiry 
message listing pane 30a. The following will explain the 
function of each command button. 

The leftmost command button 31a labeled "SETTING" 
is used to set how inquiry messages should be formatted on 

15 the inquiry message listing screen 30. Pressing this 
command button 31a causes the reply entry manager 211 to 
display a fosrmat setting dialog box (not shown) , on which 
the operator can specify his/her preferred options about 
display format. 

20 The second command button 31b labeled "LOG" is 

used to request the server 100 to provide log records of 
inquiiry messages . Pressing this command button 31b causes 
a dialog box to pop up on the monitor screen to allow the 
operator to set search conditions and the like for use in 

25 retrieving inquiry message log records. More specifically, 
the comzoand button 31b invokes a function of the first 
client 210 that is identical to what we have described as 
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the log display processor 221 in the second client 220. 
This enables the first client 210 to receive log records 
from the server 1 and present them to the operator. 

The next command button 31c labeled "DETAILS" Is 
5 used when the operator wishes to view further details of a 
particular Inquiry message. He/she selects an Inquiry 
message on the Inquiry message listing pane 30a and 
presses the DETAILS command button 31c. Then the 

Information on the selected message will appear on the 

1 0 monl tor screen . 

The rightmost command button 31d labeled "LOG OUT" 
Is used to finish the current session of browsing Inquiry 
messages. Pressing the command button 31d causes the first 
client 210 to terminate the operation of Its local reply 

15 entry manager 211. 

On the second row, the command button 31e labeled 
"REPLY" Is used to return a reply to a particular Inquiry 
message. Pressing command button 31e calls up a reply 
entry dialog on the monitor screen. 

20 The command button 31f labeled "REFRESH" Is used 

to get the latest version of Inquiry message listing. 
Pressing the command button 31f causes another delivery 
request for Inquiry messages to be sent from the reply 
entry manager 211 to the server 100. In response to this 

25 request, the Inquiry message sender 123 In the server 100 
sends back the latest Inquiry message list, and the reply 
entry manager 211 displays the received Information In the 
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inquiry message list:±ng pane 30a. 

The Inquiiry message list:ing pane 30a shows a 
plurali-by of inquiry messages 33a to 33h. The information 
of each inquiry message 33a to 33h is represented in the 
5 following fields: selection field 32a, status field 32b, 
priority field 32c, inquirer field 32d, inquiry date field 
32e, and message field 32f. Those fields have the 
following functions : 

The selection field 32a offers check boxes 34a to 

10 34h corresponding to individual inquiry messages 33a to 
33h, respectively. Each check box 34a to 34h, when 
selected by the operator, turns black (as in the fifth 
check box 34e in FIG. 5) , indicating that its 
corresponding inquiry message is selected. 

15 The status field 32b shows the current status of 

each inquiry message, which may be, for example, "W^^IT" or 
"WAIT_1H." "WAIT" means that the requesting service 
process in the server 100 is in a suspended state, waiting 
for a reply to its unanswered inquiry. "WAIT_1H" also 

20 means that the requesting service process is waiting for a 
reply, but that if there is no reply in one hour, the 
service process will resume the process according to 
predetermined settings . 

The priority field 32c shows the priority level of 

25 each inquiry message. In the example of FIG. 5, larger 
values indicate higher priorities . Those priority values 
are used as a criterion for the operator to determine 
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which inquiry message -bo answer first:. 

The inquirer field 32d shows which class of 
service processes issued -the inquiry. Such service classes 
include: "Task Manager," "Business Trip Manager," and 
5 "S'tatistics Analyzer." 

The inquiry date field 32e shows when each inquiry 
message was issued. 

The message field 32f shows the text (character 
string) of each inquiry message . This text gives a 
10 specific question to the operator, such as "Who is the 
person in charge today?" in the topmost line of FIG. 5. 

The above-described inquiry message listing screen 
30 pops up on a monitor of the client 210, which allows 
the operator to specify to which inquiry message to answer, 
15 using input devices such as a keyboard or mouse of the 
first client 210. More specifically, the operator selects 
a particular inquiry message by clicking a check box 
associated with that message. In this selection, the 
operator may take into consideration the status and 
20 priority of each inquiry in order to determine which 
inquiry should be answered first. After making the 
selection, the operator presses the "REPLY" command button 
31e, thereby moving to a reply entry dialog box. The 
operator gives an input in this dialog box, which causes 
25 the first client 210 to send to the server 100 a reply to 
the selected inquiry message. 

Inquiry messages may contain a set of choices for 
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reply, which would help the respondent to enter his/her 
answer in the correct form. See, for example, the sixth 
inquiry message in FIG. 5, the text of which reads "Put 
input data in the specified directory (l:Done 2: Abort)." 
5 The text in the parentheses suggest that the respondent is 
supposed to be choose either "1" (done) or "2" (abort) . 

As a further aid, the log display processor 221 
may display a log listing screen so that the operator can 
view past replies for reference. FIG. 6 shows an example 

10 of this log listing screen. The illustrated log listing 
screen 40 gives message log records of inquiry messages 
that were answered at 12:35 on July 1. That is, FIG. 6 
shows the result of a search for log records with a 
particular time stamp of "07/01 12:35." Message log 

15 records that match with this search criterion are 
extracted from the log memory 300 and displayed in the log 
listing screen 40. 

The log listing screen 40 of FIG. 6 actually shows 
a plurality of message log records 42a to 42e retrieved 

2 0 from the log memory 300, each of which consists of the 
following information fields: message field 41a, reply 
data field 41b, reply date field 41c, and respondent name 
field 41d. The message field 41a shows message text of 
each retrieved message log record. The reply data field 

2 5 41b tells what answer was returned to each inquiry message. 
The reply date field 41c shows when the reply was returned, 
and the respondent name field 4 Id shows who wrote that 
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reply . 

As can be seen from -bhe above, the proposed system 
offers a log listing screen 40 showing message log records, 
so that the operator can view the past replies for 
5 reference. This function permits the operator to consult 
example replies that were made correctly in the past, thus 
reducing the chance of making a mistake in answering an 
inquiry from the server 100. Further, by selecting an 
inquiry message from the log listing screen 40, the 

10 operator can call up a reply log listing screen containing 
the records of replies that were made to past inquiries 
having the same message text as the selected one. 

FIG. 7 shows an example of the reply log listing 
screen mentioned above. This reply log listing screen 50 

15 contains the following data objects: a message text line 
51 , a reply log listing area 52 , and a command button 53 . 
The message text line 51 shows the message text of a 
message log record that the operator has selected in the 
log listing screen 40 of FIG. 6. The reply log listing 

20 area 52 is where the operator can view the retrieved reply 
log records (i.e., replies to past inquiries having the 
same message text as the selected one) . Each reply log 
record shown in this field 52 consists of reply data and 
reply date. The command button 53 labeled "OK" is to be 

25 pressed by the operator when he/she has finished viewing 
the records. Pressing this OK button 53 closes the reply 
log listing screen 50 . 
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From -the above-described reply log lis-ting screen 
50, the opera-tor can learn what replies were made in the 
past, when there is a specific inquiry that he/she should 
answer. Such records of past replies help the operator 
5 determine how to answer the inquiry at hand. In the next 
section, we will explain a series of process steps from 
issuance of an inquiry API call to displaying of log 
records . 

FIG. 8 is a sequence diagram which shows a process 
10 of displaying log records. FIG. 8 depicts this process as 
a series of interactions between the following three 
groups of entities: service process 110, inquiry handler 
120, and clients 210 and 220. The process of FIG. 8 
includes the following steps : 
15 (Sll) The service process 110 issues an inquiry API 
call . 

(512) The inquiry receiver 121 receives an inquiry 
message produced by the inquiry API call . 

(513) The inquiry receiver 121 stores message data in 
20 the inquiry buffer 122. 

The cdDOve operation of recording inquiry data 
takes place each time the service process 110 invokes a 
new inquiry API call, and a plurality of inquiry records 
accimulate in the inquiry buffer 122 over time. Later, 
2 5 those pending inquiries is transmitted upon request from 
the client 210 according to the following procedure. 

(S21) In response to console input from the operator. 
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the reply entry manager 211 in the client 210 
reqpiests the inquiry message sender 123 in the 
server 100 to deliver the inquiry data. 

(522) The inquiry message sender 123, which has been 
waiting for a request from clients, now receives a 
delivery request from the reply entry manager 211 in 
the client 210. 

(523) The inquiry message sender 123 reads out inquiry 
data from the inquiry buffer 122 . 

(524) The inquiry message sender 123 produces an 
inquiry message from the inquiry data read out at 
step S23 and sends a collection of inquiry messages 
to the reply entzry manager 211 in the requesting 
client 210. 

(525) The reply entry manager 211 receives the inquiry 
messages from the inquiry message sender 123. 

(526) The reply entry manager 211 displays the list of 
inquiry messages, and then enters the state of 
waiting for console input from the operator. 

(531) The reply entry manager 211 receives an answer 
from the operator. 

(532) The entry of an answer permits the reply entry 
manager 211 to send a reply message back to the 
reply message receiver 124 in the server 100. 

(533) The reply message receiver 124 in the server 100 
receives the reply from the reply entry manager 211 
in the client 210. 
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(534) The reply message receiver 124 out:put:s the 
received reply as a return value of the inquiry API 
call initiated by the service process 110 . 

(535) The reply message receiver 124 associates the 
5 received reply with its corresponding original 

inquiry and stores them in the log memory 300 as log 
records . Each such record contains a message log 
record and a reply log record. 

(53 6) The service process 110 receives the reply, or 
10 the return value of the inquiry API call, and 

resumes the service task that has been suspended 
since the issuance of the inquiry API call . 

The above steps delivers a reply from the operator 
to the requesting service process 110 and permits the 
15 service process 110 to resume its pending task according 
to the operator's instruction. Log records of such 
interactions are accumulated in the log memory 300, which 
can be referenced by the operator at any time when he/she 
need them. The following is a process that permits the 
20 operator to consult message log records. 

(S41) In response to console input from the operator, 
the log display processor 221 in the second client 
220 requests the message log sender 125 in the 
server 100 to send message log records . This request 
25 may include some search criteria to narrow down the 

range of message log records to be extracted for 
reference purposes. The operator may specify, for 
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example, a part;±cular recep'bxon period of reply so 
as -bo obt:a±n a collec-tion of message log records 
about: -the Inquiries that were answered during the 
specified period. 
5 (S42) The message log sender 125 In the server 100 
receives the message log request. 

(543) The message log sender 125 searches the log 
memory 300 to find log records that match with the 
search criteria specified In the given message log 

10 request. If such log records are found, the message 

log sender 125 retrieves their respective message 
log records from the log memory 300 . 

(544) The message log sender 125 sends the retrieved 
message log records to the log display processor 221 

15 In the client 220. 

(545) The log display processor 221 In the client 220 
receives the message log records . 

(546) The log display processor 221 displays the 
received message log records In list form. 

20 The above steps provide the operator at the client 

220 with the records of past Inquiry messages (message log 
records) for the purpose of reference. Particularly, the 
operator may be Interested In what replies were made to 
those past Inquiry messages. The following Is a process 

25 that permits him/her to browse such Infoirmatlon (reply log 
records) . 

(S51) In response to console Input from the operator. 
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-bhe log display processor 221 in t:he client 220 
requests the reply log sender 126 in the server 100 
to send reply log records relevant to a particular 
message log record. 
5 (S52) The reply log sender 126 in the server 100 

receives the reply log request. 

(553) The reply log sender 126 searches the log memory 
300 to find such reply log records that fit the 
message log record specified in the message log 

10 request. 

(554) The reply log sender 126 sends the retrieved 
reply log records to the log display processor 221 
in the requesting client 220. 

(555) The log display processor 221 in the client 220 
15 receives reply log records. 

(556) The log display processor 221 displays the 
received reply log records in list form. 

The al>ove steps permits the operator to view the 
records of past replies madie to an inquiry. 

20 What we have described so far is the basic 

operation of the present embodiment. The present 

embodiment has various additional functions to help the 
operator to enter a reply. The following sections will 
explain those additional functions of the present 

2 5 embodiment in detail . 

Multiple-choice Selection 
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In -the present: embodiment, the reply entry manager 
211 in the first client 210 gives the operator a list of 
possible answers to a given inquiry message, thus allowing 
him/her to make a reply by selecting one of them. FIG. 9 
5 explains the concept of how the operator will do this. 
When the service process 110 needs an instruction from the 
operator, it invokes an inquiry API call with parameters 
including: message text, a reply method identifier, and a 
list of possible answers (or answer list) . The message 

10 text is a character string that explains what and how the 
operator is supposed to answer. The reply method 

identifier is actually a flag that indicates whether a 
reply is made either by selecting one of possible answers 
(multiple choice) or by entering a text string (free text 

15 input) . An answer list gives a collection of data that can 
be a reply to the present inquiry. This list is included 
as part of inquiry parameters only when "reply with 
selection" is specified. 

When an inquiry is produced as a result of an 

20 inquiry API call from the service process 110, the inc^iry 
receiver 121 stores a record of that inquiry in the 
inquiry buffer 122. This record includes message text, a 
reply method identifier, and an answer list. 

The reply entry manager 211 running on the client 

25 210 sends a message delivery request to the inquiry 
message sender 123 over the network. In response to this, 
the inquia^r message sender 123 searches the incpiiry buffer 
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122 to retrieve a relevant set of message text, reply 
method identifier, and answer list stored in the Inquiry 
buffer 122 . The inquiry message sender 123 compiles an 
inquiry message from the obtained data and sends it to the 
5 client 210 over the network. 

In the client 210, the reply entry manager 211 
receives inquiry messages from the inquiry message sender 
123, and it produces an inquiry message listing screen 30 
for display. This screen 30 allows the operator to select 

10 a desired inquiry message and gives a command to the 
client 210 (e.g., pressing "REPLY" command button 31e) to 
initiate a prescribed reply sequence. The reply entry 
manager 211 then examines the reply method identifier of 
the selected message, thus determining in what method the 

15 operator should answer. When the selected incjuiry is a 
multiple-choice type question (i.e., the respondent is to 
choose one of possible answers given in the inquiry) , the 
reply entry manager 211 produces a reply dialog box 60 
containing a list of selectable answers. When the selected 

20 inquiry is a text type question, the reply entry manager 
211 produces another type of reply dialog box 70 
containing a text box for the operator to enter reply data. 

When a multiple -choice type reply dialog box 60 
appears on the screen, the operator chooses an appropriate 

25 answer from among those shown in the answer list. When it 
is a free-text type reply dialog box 70, which contains a 
text box for data entry, the operator fills in the text 
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box using the keyboard. With the input given by the 
operator in the reply dialog box 60 or 70, the reply entry 
manager 211 delivers reply data to the server 100 by 
sending a reply message. In the server 100, the reply 
5 message receiver 124 receives the reply message, and it 
forwards the reply to the requesting service process 110 . 

FIG. 10 shows an example of the reply dialog box 
60 mentioned above. This reply dialog box 60 is composed 
of a message text line 61 showing the selected inquiry 

10 message, possible answers 62 and 63, check boxes 64 and 65 
for respective answers, and command buttons 66 and 67. 

In the example of FIG. 10, the message text 61 
reads "Move files to the specified folder . " This is 
followed by two possible answers 62 and 63, which read 

15 "Done" and "Abort," respectively. Attached to those 
answers 62 and 63 are check boxes 64 and 65, respectively. 
The operator selects the first check box 64 when his/her 
reply is "Done, " or the second check box 65 when he/she 
wishes to "Abort. " The operator is allowed to choose 

20 eitiier the first check box 64 or the second check box 65 
exclusively. In other words, selecting one check box will 
cause the other check box to become deselected 
automatically 

The left command button 66 labeled "OK" allows the 

25 current reply data to take effect. That is, when this OK 
button 66 is pressed, the reply entry manager 211 produces 
a reply message containing the selected answer and sends 
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it back to the server 100 over the network. The right 
command button 67 labeled "CANCEL," on the other hand, is 
used to cancel the entry of an answer. Pressing, the 
command button 67 closes the reply dialog box 60 without 
5 transmitting a reply. 

FIG. 11 shows an example of a reply dialog for 
free-text type inquiries. This reply dialog box 70 is 
composed of the following elements: a message text line 71 
showing the selected inquiry message, a text box 12, and 

10 command buttons 73 and 74. 

In the example of FIG. 11, the message text 71 
reads "Who is the person in charge today?" The text box 72 
is the field where the operator enters his/her answer. The 
operator uses a keyboard or other input devices to fill in 

15 -tiie text box 72 with character strings as his/her answer 
to the given inquiry. 

The left command button 73 labeled "OK" allows the 
current reply data to take effect. That is, when this OK 
button 73 is pressed, the reply entry manager 211 produces 

20 a reply message^ containing the: answer in the text box 72 
and sends it back to the server 100 over the network. The 
right conamand button 74 labeled "CANCEL, " on the other 
hand, is used to cancel the entry of an answer. Pressing 
this command button 74 closes the reply dialog box 70 

25 without transmitting a reply. 

The next section will now describe the processing 
steps that deal with a multiple-choice type inquiry. 
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FIG. 12 ±s a sec[uence diagram which Includes a 
process of multiple-choice selection. The process is 
visualized as a series of interactions between the 
following three groups of processing entities : service 
5 process 110, inquiry handler 120, and clients 210 and 220. 
The process of FIG. 12 includes the following steps. 

(561) The service process 110 issues an inquiry API 
call. Parameters of this inquiry API call include a 
reply method identifier and an answer list. For 

10 example, the reply method identifier may specify 

"multiple-choice type , " and it is accompanied by two 
possible answers , "Done" and "Abort , " to the 
question w 

(562) The inquiry receiver 121 receives an inquiry 
15 message produced by the inquiry API cal.1. 

(■S63) The inquiry receiver 121 records the received 
inquiry in the inquiry buffer 122 . 

The inquiry is delivered afterwards to the 
client 210 upon request, as will be described in the 
20 following; steps S71 to S74. 

(S71) In response to console input from, the operator, 
the reply entry manager 211 in the client 210 
requests the inquiry message send<er 123 in the: 
server 100 to deliver pending inquiries . 
25 (S72) The inquiry message sender 123 in the server 100 

has been waiting for data delivery request from 
clients. It now receives the data request that the 
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reply entry manager 211 In the client 210 Issued at 
step S71. 

(S73) The xnqulry message sender 123 reads out Inquiry 
data from the Inquiry buffer 122 . 
5 (S74) The inquiry message sender 123 compiles an 

inquiry message containing each inquiry read out of 
the inquiry buffer 122 and sends them to the reply 
entry manager 211 in the client 210. An inquiry 
message contains a message text string and a reply 
10 method identifier. In the case the reply method 

identifier indicates that the question is of 
multiple-choice type,, the message further carries a 
list of possible answers. 
CS75) The reply entry manager 211 in the client 210 
15 receives inquiry messages from tJie inquiry message 

sender 123. 

(;S76) The reply entry manager 211 examines the reply 
method idientifier of each message. If the reply 
method identifier indicates multiple-choice- 
20 selection,, the process advances to step S77 . If- it 

indicates free text entry, the process advances^ to 
step S79. 

(S77); The: reply entry manager 211 displays a reply 
dialog box that contains a list of selectable 
25 answers:. 

{SI 8) The reply entry manager 211 receives an input 
indicating which answer the operator has selected 
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from among, those shown xn the dialog box. The 

process then proceeds to step S81 . 
(S79) The reply entry manager 211 displays a^ reply 

dialog, box for free text entry. 
5 (S80) The: reply entry manager 211 receives an answer 

that the operator has entered to the text box in the 

reply dialog box. 
(S81) The reply entry manager 211 sends the received 

answer to the reply message receiver 124 in the 
10 server 100 as a reply to the inquiry of interest. 

(:S82) The reply message receiver 124 in the server 100 

receives the reply from reply entry manager 211 in 

tJie client 210. 

(583) The reply message receiver 124 outputs the 
15 received reply as the return, value of the inquiry 

API call initiated by the service process 110 . 

(584) The reply message receiver 124 associates the 
received reply with its corresponding origina^l 
inquiry and' stores botii of them (i.e., a message log 

20 record and a reply log record) in the log memory 300 

as. a new log record entry . 

(585) c The service process 110 receives the reply,, or 
the return value of the inquiry API call, and 
resumes the task that has- been suspended since^ the 

25 issuance of the inquiry API call. 

Through the above steps, the operator can answer an 
inquiry by selecting an appropriate item from a list of 
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given possible answers when the Inqulxry's reply method 
identifier indicates the use of a multiple-choice 
selection method. 



Browsing Reply Log Records 

5 This section describes a process executed by a- 

client 210 in order to allow the respondent to consult the 
records of past replies when he/she makes a reply. FIG. 13* 
is a conceptual view of such an answer selection process. 
The illustrated process is initiated by the service 

10 process 110 in the server 100, which issues an inquiry API 
call when it needs some instructions from the: operator. In 
response to the inquiry API call, the inquiry receiver 121 
produces a new entry for the inquiry buffer 122 to store 
ther content of the inquiry . The reply entry manager 211 

15 running on the client 210 sends a message delivery request 
to the* server 100 over the network. This causes the 
inquiry message sender 123 in the server 100 to retrieve 
pending inquiries from: the^ inquiry buffer 122:. The^ inquiry 
message sender 123 also searches t^e log. memory 300 in an. 

20 attempt to; find reply log records that match with each, 
pending inquiry in terms of, for example., the similarity 
of message text. The inquiry message sender 123 then 
compiles inquiry messages from the records retrieved from 
the inquiry buffer 122 and log memory 300 and sends them 

25 to the client 210 over the network. 

In the client 210, the reply entry manager 211 
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receives the inquiry messages sent: from the inquiry 
message sender 123, and it produces an inquiry message 
listing screen 30 for display. This screen 30 allows^ the 
operator to select an inquiry message and commands the 
5 client 210 to activate a reply procedure by> for example, 
pressing the "REPLY" command button 31e. When there are 
reply log records relevant to the selected inquiry message, 
the reply entry manager 211 outputs: a reply dialog box 
containing a list of reply log records (e.g., reply dialog 

10 box 80 with a past reply list described later). The 
operator may find an appropriate item in the list of reply 
log records displayed on the screen. Xf this is the^ case, 
the operator selects that record as an answer. Or if this 
is not the case, including when there are no relevant log 

15 records , the: operator can type^^ in the answer in the. dialog 
box. 

The reply entry manager 211 sends a reply message 
to the reply message- receiver 124 over the^ network. Upon 
receipt of: the reply, the reply messager receiver. 124 hands^ 

20 it over to: the- service, process^ 110 ,. and at the same^ time, 
it saves a log record- in the log memory 300, which 
includes: message text, reply data,, reply date, and other 
related items . 

FIG. 14* shows an example of a reply dialog box 

25 with a list of past replies. The illustrated reply dialog 
box 80 has the following elements: a message text line 81 
shown in the inquiry of interest,, a text box 82 for 
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en-berxng. an answer, a reply log field 83, and two command 
buttons 84 and 85. In this example of FIG. 14, the message 
text 81 reads "With which office will transactions take 
place today?" The text box 82 is used by the operator to 
5 enter his/her answer. The reply log. field 83 shows a list 
of reply log records, i.e., the records of replies that 
were made to past inquiry messages with the same content 
as the one that the operator has chosen. When the operator 
selects oner of those reply log records, the selected 

10 record is copied into the text box 82. For example, FIG. 
14 shows: a situation where the operator has selected^ "West 
Branch Office" from the list. 

The left command button 84 labeled "OK" is pressed 
by the operator when he/she wishes the current content of 

15 the^ text box 82 to be seni: out as the answer. Pressing 
this OK button 84 permits the reply entry manager 211 to 
take in the content of the text box 82 and transmit it as 
a reply message to the reply message receiver 124 in. the 
server 100. The right command button 85 l^eled "CANCEL." 

20 isr used to cancel the entry of an. answer. Pressing; this 
command button 85 closes: tii&- reply dialog box 80 without 
transmitting a reply.. 

The: operator can reuse the records of past replies 
to answer, av given inquiry message in the way described 

25 above, with- reduced possibilities of making a mistake in 
entering a text string. This feature of the present 
embodiment makes the operator ' s job easy particularly when 



-43- 



he/she has to answer similar ques-bions xoany txmes . 

Answer Lxsi: and Reply Log; Records 

While we: have^ described -bhe use of an answer list: 
and a reply log list: as separate reply methods. It Is 
5 possible to combine those two methods. In this case, the 
service process 110 gives a reply method Identifier to 
each Inquiry API call as an additional parameter. When, the 
reply method Identifier Indicates that a multiple-choice 
selection should be made, an answer list will be given as 

10 an additional parameter of an Inquiry API call.. Such data 
of each Inquliry Is saved. In the Inquiry buffer 122 • 

When- a message delivery request Is received from 
the reply entry manager 211, the Inquiry message^ sender 
123 searches the Inquiry buffer 122 to retrieve pending 

15 Inquiries, Including their message text, answer lists, and 
reply metiiod Identifiers. The Inquiry message sender 123: 
further searches the log memory 300 to find log records 
relevant to: each pending Inquiry . Messages addressed to: 
the reply entry manager 211 Include* all those data Items 

20 obtained from the Inquiry buffer 122^ and log memory 300. 

Upon receipt of an Inquiry message, the reply 
entry manager 211 first examines: Its reply method 
Identifier to. determines what reply method Is specified. 
When the Inquiry turns out to be a multiple-choice type 

25 question, the reply entry manager 211 produces a reply 
dialog box containing an answer list. The operator can. 
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choose an approprla-be answer from among the possible 
answers displayed on the monitor screen.. When, on the 
other hand, the inquiry is a- text type question., the reply 
entry manager 211 produces a reply dialog box with a text 
5 box to allow the operator to enter an answer. Further, if 
there are relevant reply log records, the reply entry 
manager 211 includes tiiose records in the reply dialog box, 
thus- allowing the operator to choose one of the past 
answers if he/she finds it appropriate. The reply entry 
10 manager 211 sends the selected answer to the reply message 
receiver 124 in the server 100 as a reply to the inquiry. 

Handling^ Reply Timeouts 

This section describes timeout processing for 
inquiries pending in the inquiry buffer 122 . FIG. 15 is a 

15 functional block diagram of a server with timeout 
processing functions. While the illustrated server 100 
actually has: various functions, FIG. 15 shows a limited 
number of elements^ that, arer related to timeout processing, 
which arer a. servicet process 110, an inquiry receiver 121, 

20 an inquiry buffer 122, and a timeout handler 127. Timeout 
processing is achieved through the^ cooperation^ between 
i^eset elements . 

The: service process 110 issues an inquiry API call 
when it needs instructions from the operator. The inquiry 

25 API call from the service process 110 produces an inquiry, 
and the incjuiry receiver 121 saves this inquiry in the 
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inquiry buffer 122. The role of the timeout: handler 127 is^ 
in short, to check the expiration of a predef ined\ timeout 
period for each pending inquiry in the inquiry buffer 122 
and notify the service process 110 of the timeout event 
5 when it happens. More specifically, this timeout detection 
process follows the steps described below. 

When it needs instructions from the operator, the 
service process 110 issues an inquiry API call to the 
operator,, with a piece of message text as one of its 

10 parameters. The issuance of such an inquiry API call 
causes the inquiry receiver. 12:1 to produce a new entry for 
the inquiry buffer 122, which contains: inquiry data (e-g. , 
message text) and expiration time: in an associated manner. 
Here, the expiration time is- calculated by adding a 

15 predetermined timeout period to ther issuance time: of the 
inquiry API call .. 

The timeout handler 127 makes access to the 
inquiry buffer 122 at regua:ar intervals to read out each 
set of inquiry data and expiration time (step S91) . The 

20 timeout handler 127' then checks^ the status of every 
pending inquiry and determines: whether their expiration 
times, have: been reached (step* 892:); Ifr the expiration time 
of a particular inquiry has: been reached, the timeout 
handler 12.7' recognizes it a& a^ timeout of that inquiiry. 

25 The timeout handler 127 then returns a cancel code to the 
requesting service process 110, indicating that the 
pending, inquiry has been expired. Non-expired inquiries 
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remaxn in -bhe Inquiry buffer 122 and are subjected' t:o ^he 
next 'tlmeou't checking task after a predetermined cycle 
period . 

The aforemen'tloned timeout: period may be specified 
5 as^ a s'tart:up parame-ter or defined In an. Inl-tlallzatilon. 
file (e.g. , INI file) . Expiration t:lmes may be calculated, 
nol: beforehand, bu-t a-t t:he time each pending inquiry is 
tested. In this case, Uie Inquiries are stored in. the 
inquiry buffer 122, together with -their respect^lve 
10 Issuance t:imes.. 

Timeout Period specified by Service Processes 

The: 'timeout: period of each inquiry may also be 
specified by the reques-ting service process 110 when it 
issues an inquiry API call. In -this; case, the service^ 

15 process 110 gives a 'timeout period value- as one of t:he 
parameters of: each inquiry API call that it. issues. Upon 
issuance of: such an inquiry API call, -the inquiry receiver 
12:1. produces: a new entry for the inquiry buffier 122, which 
contains: Inquiry data (e .g. , message text) and the 

20 corresponding expiration tdLme parameter. Expiration time 
of each inquiry is- calculated by adding the specified 
timeout period: to the issuance time of t^e inquiry API 
call Instead of storing calculated expiration times: in 
the inquiry buffer 122 , the inquiry receiver 121 may save 

25 their original API call issuance times and specified 
timeout periods, togetJier with the corresponding inquiry 
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da'ba. 

The -timeout handler 127 makes access to the 
Inquiry buffer 122 at regular Intervals in order to read 
out. each set o£ inquiry da^ta and expiration 1:ime (step 
5 S91) . The timeout handler 127 then checks the st:at:us of 
every pending; inquiry and determines whether its 
expira-tion time has been reached (step S92) . If the 
expiration time of a particular inquiry has been reached, 
the -timeout handler 127 recognizes it as a -timeout: of -that 

10 inquiry. The timeout handler 127 then returns a cancel 
code to the requesting service process 110, indica-ting 
that the pending^ inquiry has been, eacpired.. 

While -there is only one service process in the 
example of FIG. 15, the real-world system may have a 

15 plurality of such processes. Therefore, -the method 
described in -tJiis section makes it easy for the individual 
service^ processes^ -to specify timeout, periods of pending 
inquiries independently of each other . 

Timeout Period Identifiers 

20 Inquiry API calls produced by the service^ process 

110: may have a -timeout, period identifier as one of its 
parameters,, so -Uia-t. -the -timeout handler 127 can. determine 
the- leng-m of timeout period from, -that timeout period 
identifier. TO this end, a timeout period table has to be 

25 created previously for use by -the timeout handler 127. 

FIG. 16 shows an example, of a timeout period table. 
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The illust:rai:ed txmeou-b period table 90 defines multiple 
sets of a timeout period identifier and its^ corresponding 
time length. More specifically, this t^le 90 contains ten. 
entries of timeout period identifiers "PRiOl" to "PRI09," 
5 each of which is assigned a specific timeout period, in 
units of minutes .. The text in the parentheses suggests the 
time length in units of hours or days or weeks. In the 
example of FIG. 16, timeout period "PRIOl" is set to 60 
minutes (one hour) . Timeout period "PRI02" is set to 180 

10 minutes (three hours:) . Timeout period "PRI03" is set to 
360 minutesi (six hours); Timeout period "PRI04" is set to? 
72-0: minutes (twelve hours): Timeou^t. period^ "PRI05" is set 
to 1,.080 minutes ({eighteen hours) . Timeout period "PRI06" 
±S: set to 1,440 minutes (one day) . Timeout period "PRI07" 

15 isi set to 2880 minutes: (two days) . Timeout period "PRI08" 
isv set to 4v, 320 minutes^ (three days.)/. Timeout period 
"PRI09" is set to 10,080 minutes (one week^ . 

As can be seen from the aibove example of the 
timeout period ta£>le^ 90, a different timeout: value is 

20 assigned to each different: tdLmeout period, identifier . In. 
the- server 100,. the^ timeout period t^le 90 may be defined 
as- part of a systems configuration file (e.g. , INI file); or 
envtered through a graphical user interface (GUI): for 
configuration, setup. 

25 Suppose, for example, that the service process 110 

needs: an. instruction from the operator. Then it invokes an 
inquiry API call including a piece of message text and an 
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appropriable timeout: period ident:ifier as parameters. This 
inquiry API call causes the inquiry receiver 121 to 
consult the timeout period table: 90 to read out the value: 
of timeout period corresponding, to the specified timeout 
5 period identifier. The inquiry receiver 121 then adds: the 
obtained timeout period to the issuance time of the; 
ongoing inquiry API call, thereby calculating an 
expiration time. This expiration time is entered to the 
inquiry buffer 122, together with other data relai:ed to 

10 the inquiry . 

The timeout handler 127 makes access to the 
inquiry buffer 122 at regular intervals to examine the 
expiration of each pending inquiry, and if the expiration, 
timer of a particular inquiry has been reached, the timeout 

15 handler- 127' recognizes that inquiry message as an expired, 
message. The: requesting server program module t^us 
receives- a- cancel code indicating that the pending inquiry 
should be: canceled due to timeout. 

EI&^ 1.7- shows an example^ of timeout processing 

20 using a timeout, period table in such a situation, where^ no 
response has: been returned from the operator before the. 
expiration time is reached. 

In response to some console- input, from- tJie 
operator,, the inquiry receiver 121. enters sets of timeout 

25 period identifiers and corresponding timeout periods. When 
it needs instructions from the operator, the service, 
process 110 issues an inquiry API call with a timeout 
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perxod ±dent.ifler a-b-bached as a paxaxnet:er . The parameters^ 
of this inquiry API call include, for example,. the 
following items: message text "Put Input Data in. the 
Specified Directory," an answer list "Done/Abort," and a 
5 timeout period idientifier "PRI02," 

As previously mentioned, the timeout period for 
identifier "PRI02" is three- hours. The inquiry receiver 

121 adds this threes hours to the current time of day, 
thereby calculating the expiration, time of the ongoing 

10 inquiry API call (step SlOl) After that, the inquiry 
receiver 121. saves the: new inquiry in. the inquiry buffer. 

122 (step S102) , including the message^^ text, possibler 
answers, and expiration time. Note that this may not 
necessarily be^ the sole content of the inquiry buffer 122. 

15 Rather,, the inquiry buffer 122 may have^ accumulated like 
inquiries- produced by other servicer processes. 

Ther timeout handler 127 checks the^ expiration time 
of each pending inquiry (step S103)i . If the e^iration^ 
time^ of a particular, inquiry is; reached, the timeout 

20 handler 12:7 returns: a. cancel code^ to the requestingi 
service process^ 110:, indicating tha^ the pending inquiry 
has been expired (tstep S104) . This allows; the server 
program to resume execution, taking a path to: its cancel 
routine Fbr otiier non-expired inquiries (step S105): ,. the^ 

25 timeout handler 127 waits for a predetermined period (e. g. , 
one minute) and then goes back to step S103 to check the? 
expiration times again.. 
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FIG. 18 is a sequence diagram showing, a procedure 
of timeout: processing. FIG. 18 depicts -bhis process as a 
series of interacbions between the service process 110 and 
inquiry handler 120 . 
5 The service process 110 issues an inquiry API call 

when it needs an instruction from the operator (step Sill) . 
This inquiry API call, has the f ollowing paramet:ers : 
message tex't "Put inpu-t data in the^ specif ied directoary" ; 
a reply method identifier "Multiple-Choice" ; an answer 

10 list "Done/Abort,"; and timeout period identifier "PRE02" 
(or a specific timeout value); .. The service process 110 
tiien- puts: itself: into^ a wait state and. stays there, until 
tile API: returns control to the^ caller . 

The inquiry API call invoked at step Sill is 

15 directed^ to the: inquiry receiver 121 in. the inquiry 
handler 120 (step S112) . The inquizry receiver 121 saves 
th&T received inquiry data in the^ inquiry buffer 122 (step 
S113) . Subsequently thev inquiry receiver 121 consults the 
timeout period table^ to; obtai:n. the valuer of: timeout period: 

20 corresponding to. the specified timeout period* identifier. 
The inquiry receiver 121 calculates an expiration time: by 
adding the timeout period to> the present timer of day ('Step> 
S114v)^. The^ calculated: expiration time ia then, stored in 
tile inquiry buffer 122 , togetiier with other data about tdie 

25 inquiry. 

The reply message receiver 124 waits a reply from 
the reply entry manager 211 in the client 210 (step S115) , 
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while wa-tchlng, the time elapsed since the API call. When 
there is a reply message from the operator ("YES" a^t step- 

5116) , the reply message receiver 12 4^ f orwards it to tile 
service process 110 . Then the service process 110 uses the 

5 result of the incjuiary as setup parameters or the like: and 
returns to its original service task (step S119) . When^ on 
the other hand, a predetermined period (e .g. , one minute) 
has. passed without receiving a reply ("NO" at step S116) , 
the- timeout handler 127 compares the expiration time> of 
10 the pending inq[uiry with the present time of day (step 

5117) r . If the: expiration time: is- not reached ({"NO" at step 
S117)) , thei timeout handler 127 goes back to step S115 for 
another round. If: the expiration time has been, reached 
("YES at step S117) , the timeout handier 127 returns 

15 control to the^ caller of the inquiry API call (step S118) . 
The- caller,, or the service process* 110,. accepts the 
timeout Cor cancellation) of its: inquiry and thus resiomes 
the original service task, accordingly (step S119) . 

For- timeout* processing, the: inquiry buffer 122 and 

20 log* memory 300. are structured as- follows .. FIG-. 19- showsr an> 
example! of data structure of the inquiry buffer 122. As^ 
can be seeni from this; drawing, the inquiry buffer: 122 
stores a pluxality of inquiry records 122a to 122n, each 
produced by a newly issued inquiry API call. Each inquiry 

25 record 122a^ to 122n^ contains the following correlated data^ 
items: inquiir^ date, reply method identifier, inquirer, 
message text, answer list, and timeout period identifier. 
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The inquiry date field shows when the inqpiiry API call was 
issued by a service process 110 . The reply method, 
identifier indicates which reply method to use (e.g. , 
multiple-choice selection or free text entry) . The 
5 inquirer filed contains a code for identifying^ which 
service process 110 has invoked the inquiry API call. The 
message text field shows the text of a message addressed* 
to the operator. The answer list is an optional field that 
contains possible answers to the inquiry, which is 

10 included^ only when a multiple-choice method is specified. 
The- timeout period identifier specifies the length^ of 
timeout period:.. 

FI6.. 20 shows a specif ic example of data stored in: 
the inquiry buffer 122. In this example, the topmost entry 

15 122a represents an inquiry with the following properties: 
inquiry date = "2002/01/01 12:00:00" . 

• -reply method identifier = "Free Tiext" 

• inquirer = "Task Manager" 

message; tex4:. = "Who is: the person in charge: today?" 
2 0 • timeout period, identif ier = "PRI02 " 

The next entry 122b represents another inquiry with, the 
following properties r 

• inquiry date = "2002/01/01 12: 10: 00" 
reply method: identifier = "Multiple-Choice" 

25 • inquirer == "Business Trip Manager" 

• message text = "Select the place you are visiting for 
business" 
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answer list = "Tiokyo Off xce/Headquarters/Nagoya Sales. 
Office" 

timeou-b period identif ier = "PRI03" 
Likewise, the bottommost entry 122n represents yet another 
5 inquiry witJi the: following properties : 

inquiry date = "2002/01/01 17:30:00" 
reply method identifier = "Free Text" 
inquirer = "Statistics Analyzer" 

message text = "How many people are standing by in the 
10 office^ now?" 

timeout period identifier = "PRIOl" 

As can be seen from the above example, the present 
embodiment uses a timeout period table for management of 
each inquiry ' s timeout period^. This feature enables 
15 timeout periods to be: changed^ without affiecting the design 
of tiie- service^ process 110 . 

FIG. 21 shows an example of data structure of the 
log, memory 300. As can be seen from this diagram, the log 
memory 300 storesF a plurality of; log records: 300a to 30 On., 
20 each> produced when a^ reply is returned^ or. a timeout event 
occurs • Each log record 300a to 30 On contains the 
following data field:: inquirer,, message^ text, answer,, 
reply date, respondent name,, and: replying host name. The^ 
inquirer filed contains a code for identifying which. 
25 service process 110 originated the inquiry API call. The 
message text field shows the text of a message that was 
presented to the operator. The answer field shows the 
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result of -the inquiry, which was received: from -bhe reply 
entry manager 211. The reply diate field Indicates when the 
reply was received from the reply entry manager 211. The 
respondient. name field shows who (or which operator) 
5 actually responded to the: Inquiry. The respondent host 
name gives a unique Identifier of a host that the operator 
used> to send an answer. This Information Is used to locate 
the^ responding, client 210 . 

The above-described data Items contained in each 

10 log record* 300a to 30 On are divided into two groups: 
measage> log. records: and"^ reply log records .. That, is,; tile: 
Inquirer Information and message- text fall into tiie 
message^ log; group, while the answer, reply- date, 
respondent name, and^ respondent host name fall, into the 

15 reply log group . 

FI6>. 22 shows a specif ic example of data stored in 
the. log memory 300 . Specif ically, the topmost log- record 
300a lncludies> the: following data, items: 

• * inquirer: = "Task Managjer" 

20 message^ text = "Who is: the^ person in charge^ today?" 

♦ answer = "Suzuki." 

reply date - "2002:/01/01 13:10:00" 
respondent name = "Suzuki."' 
respondient host name "hostA" 
25 The next log record 300b Includes the following data 
items : 

* inquirer = "Business Trip Manager" 
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• message tiex'b = "Select the place you are visiting for 
business . " 

answer = "Nagoya Sales Office" 

• reply date = "2002/01/01 13:20:00" 
5 respondent name: = "Suzuki" 

replying host name = "hostB." 
The bottommost log record 300n includes Idle following data 
items : 

inquirer = "Statistics Analyzer " 
10 message text = "How many people are: standing by in the 

office- now?*" 
^ reply time. = "2002/01/01 17:30:00" 
answer = "Timeout" 
Note that the answer field of this log record 300n. is 
15 "Timeout," meaning that the issued inquiry API call ended^ 
up' witii^ a timeout . 

Supplementary Features of Timeout Handling: 

(a) Logging ea^ired^ inquiries- 

When ant inquiry is^ cancelled due; to timeout, the 
2 0 tdLmeout handler 127 records it in. the. log memory 300: by 
entering a message log record of the- canceled inquiiry> as^ 
well as a reply log record that indicates the occurrence: 
of the^ timeout. 

(b) Showing inquiry messages with expiration times 

25 In the> case an entry of the inquiry buffer 122 has 

a field value of expiration time, that value may be shown 
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in an Inquiry message listing screen as an add;i1:ional 
piece of inf ormat:ion rela-ted to the pending inquiiry 
message. More specifically, the inquiry message sender 123' 
sends to the^ reply entry manager 211 an. inquiry message: 
5 containing an expiration time . The reply entry manager 211 
displays an inquiry message listing screen, emphasizing 
inquiry messages whose timeout periods will soon expire. 
Emphasis on such messages can be achieved by, for example, 
changing the color of message characters, using a^ 
10 different font, or adding a special icon. This feature 
helps; the operator notice IJiose soon- to -be -expired inquiry 
messages 

Executing Command in response to Reply 

According to the present embodiment of the 
15 invention., the- server 100 can be configured to execute a 
predietermined command in response to a^ reply given by the 
operator. FIG'. 23 ±3. a conceptual view of a process which 
executes^ a command according: to a^ given, reply. When, it 
encounter sr an event that needs^ an. instruction, from, the 
2 0 operator, the servicer process^ 110 invokes: an inquiry API 
call, with parameters including a^ message^ text string of 
inquiry and a command line that will be^ executed when the 
inquiry is answered. Upon issuance of this; inquiry API. 
call, the inquiry receiver 121 stores the message data and 
25 command string in the inquiry buffer 122. 

The reply entry manager 211 running on a client 
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210 sends a message delivery request 'to the Inquiry 
message sender 123 in the server 100 over the network. The 
inquiry message sender 123 compiles inquiry messages 
containing inquiries retrieved from the inquiry buffer 122 
5 and sends them to the reply entry manager 211. The reply 
entry manager 211 produces an inquiry message listing 
screen, accordingly. From among those^ listed on the screen, 
tiie operator chooses one: message tiiat he/she is going to 
respond to and answers that inquiry message.. The reply 

10 entry manager 211 sends the reply to the reply message 
receiver. 124 over: the^ network. Besides forwarding the 
received reply to the^ service, process 110, the reply 
message receiver 124 executes the command string 
previously specified in the inquiry API call . 

15 Such commands are a^llowed' to reference: the content: 

of a reply- message^ as^ its> input parameter. Suppose a- 
situation:^ where the service process 110 needS' a^ piece of 
input, data fromv the^ operator before^ it. can. execute* an 
instruction', "commandl," for example. The: service^ process: 

20 110 issuea anv inquiry API. call to accomplish. its= ongoing 
task. Parameter sr of this inquiry API call include,, among 
others ,, the: f ollowing data items r message: text, that reads^,. 
for example,, "Put input data in the specified directory"; 
an answer list "Done/Abort"; and. a command string 

25 "commandl" that will be: dispatched' upon receipt of ar reply . 
The inquiry receiver 121 stores an inquiry with those 
parameters in. the incjuiry buffer 122 . 
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The opera t:or act:xvat:es the reply en -try manager 211 
on -bhe client: 210. The reply ent:ry manager 211 receives 
inquiry messages (con-taining message text and answer list) 
from the> inquiry message sender 123 over tiie network and 
5 produces an inquiry message- listing screen. Those 
inquiries are^ based on what have been stored in the^ 
inquiry buffer 122. Browsing through the inquiry message^ 
listing screen, the operator finds a message^ that asks: 
him/her to enter input data, whose text line is "Put input 

10 data in the specified: directory." The operator thus: enters, 
required data in the specified directory.. He/she then, 
comes back to> t3ii& inquiry message listing; screen and 
selects- the inquiry message of interest, which causes the- 
reply entry manager 211 to produce a dial.og box that 

15 prompts^ him/her to select either "Done" or "Abort." The 
operator chooses^ "Done" in this dialog box. With this 
answer, the reply entry manager 211 sends a reply message 
to the reply message: receiver 124 over tiie- network, 
indicating the selection of* "Done^" as an answer.. The: reply 

20 message^ receiver 124; returns' a reply (("Done^") to: the^ 
service^ process: 110 . 

With the above: response , the reply message 
receiver: 12'4^ reflers to "Uie relevant record in. the^ inquiry 
buffer 122 and finds that there is a command to execute. 

25 The reply message receiver 124' thus dispatches the command 
("command!" in this case) to the operating system of the 
server 100, attaching a parameter "Done" if so required. 
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This permlt:s 'the service process IIO- net only -to resiime^ 
the pending, service task, but also to execut^e the coxmnand 
"commandl" according, -to the received reply. 

FIG. 24 Is a sequence diagram of a process: "that 
5 dlspa-tches a^ comxaand according; 'to a given reply. FIG. 24> 
depicts the process as a series of In'teractlons between^ 
th,& following tiiree groups of: processing; entl-tles : service: 
process 110, Inquiry handler 120, and reply ent:ry manager 
211. 

10 The service process^ 110^ Issues^ an Inquiry API call 

when. I't. needs^ slth Insl^iruct^lon from^ tiie^ operator (step 8121)^.. 
This Inquiry API call hast t:he following parameters:: 
message tex-t "Pu^ Inpu^ dat:a^ In the^ specified directory" ; 
a reply method Identifier "Multiple -Choice" ; an answer 

15 list "Done /Abort"; and a command string "commandl" to be 
dispatched.. The^ service process 110 then puts Itself Into 
a^ wait state- and: stays there^ until the^ API returnS' control, 
to^ t!h& caller:. 

The^ Inquiry API call. Issued at. step S121 arrives^ 

20 ett: 'tile: Inquiry receiver 12:1. ini "the^. inquiry handler 120: 
(step S122:); . The Inquiry receiver 121 saves? the received, 
data in the. inquiry buf fer 122 Cstep^ S123); . The reply 
message receiver 12:4 waits for a reply from the reply 
entry manager 211 in the client 210^ Cstep S124) . 

25 In\ response: to console input from the: operator, 

'Uie reply entry manager 211 in the client 210 requests^ the 
inquiry message^ sender 123 in 'the server 100 to deliver 
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pending. Inquiries (si:ep S125) . The Inquiry- message sender 
123 then retrieves Incjulry data from the: Inquiry buffer 
122 (step SI26) and sends them as Inquiry messages to the 
requesting, reply entry manager 211 (step S127). . 
5 The reply entry manager 211 In the: client 210 

receives Inquiry messages: sent from the^ Inquiry message 
sender 123 (step S128) and outputs them on an Inquiry 
message- listing screen (step S129) . Browsing through ther 
Inquiry message listing screen, the operator finds a 

10 mes:sager with a text line of "Put Input data in the 
specified^ directory,," which, asks him/her to enter input 
data^.. The^ operator tJiusi enters required da^a in a^^ 
specif led' directory.. He/she. then comes> back to. tiiev inquiry 
message listing screen, selects the inquiry message he/she 

15 has^ just answered, and^^ enters: "Done" as: the^ answer. The: 
reply envtry manager 211 accepts this answer, (step S130) 
and. sends: a reply message to the reply message receiver 
124^ over the- network (step S131)' . 

The- reply message^ arrives; a^: 'Ulei reply message: 

20 receiver. 12:4- in the server 1.00 (-step SI 32)/, which^ permit Sr 
ther service process: 110. to: receive a returm vallue; as. a. 
result of its inquiry API caOll (step^ S133)} . Subsecpientiy „ 
the. reply message receiver. 12:4. makes access> to the inquiry 
buffer 122: to retrieve^ a. command relevant to the^ reply and. 

25 dispatches the command to^ the operating system or other 
appropriate processing facilities (step S134) . Then the 
reply message receiver 124 stores a log records in the log 
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memory 300 (step S135) . The service process 110 uses the 
result of the inquiry as setup parameters or the like^ and 
returns to: its original service^ task (step S136) . 

Advantages: of the Invention 

The: above-described embodiment of the present 
invention, has the following advantages: 

(a) The- operator can easily retrieve and browse: tAe 
records of past inquiry messages and their 
respective replies. The^ proposed system^ allows^ tJie 
operator, to consult past: examples as necessary,, thus: 
helping, him/her to find an appropriate answer, to the^ 
current: inquiry message. 

(b) The inquiry message listing screen permits tiie^ 
operator to select and answer a particular inquiry- 
seamlessly, thus eliminating the chance of 
misdirecting an answer to a different inquiry 
message^.. More specif icaJ.ly,. conventional systems; 
require: the^ operator to: specify an inquiry message: 
by entering its; identifier or the like.. This means: 
tha^: there^ is a possibility for him/her to enter a^ 
wrong identifier,, and in that case,, his;/her answer 
could, bei directed to an unintended inquiry . Unlike 
thosei conventional systems, the present invention, 
provides a seamless procedure- from selecting an 
inquiry to writing an answer, preventing irrelevant 
inquiries from being specified as the destination of 
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the answer. The present inventxon Improves^ the 
rellabllxty of computer systems sxnce ±t. Is ensued^ 
that the operator can write answers^ to intended^ 
inquiries . 

5 (c) Answers are free from syntax errors when they are 

entered through multiple-choice^ selection facilities: 
of the proposed system. Besides improving, the^ 
reliability, this feature of the present invention 
reduces a psychological burden on the operator. The 
10 present invention^ also: makes* it easy to develop: 

server: programs, because the service: process d^oes^ not 
need: to care: about^ whether each received^ answer: is* 
semantically correct or not. 

(d) Wi.th^ its> timeout, handling mechanisms, the^ proposed. 
15 systaa allows service functions^ to* continuev 

canceling pending inquiries when there: is no reply 
from^ the operator.. This feature; of the present 
invention prevents a server from^ running out of 
Gonrputer resources^ (e . g.. , main. memosryX , which can 

20 happens in. conventional servers: when many service- 

processes go into wait, starte because of their 
unanswered^ inquiries. In other word's^,, the present 
invention. improves^ tiie- efficiency of service^ 
processing by cutting off: needless^ process: 

2 5 synchronization . 

(e) Inquiry API calls can automatically dispatch a^ 
desired command when they are answered. This feature^ 
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is used' to automa'te post-inquiry processing, (e . g;. , 
completion notification for a reply) in service 
tasks:. 

We have described, preferred embodiments of the 
5 invention, assuming that the operator uses two separate- 
clients 210 and 220, the former for entering answers and 
the latter for browsing log records. We^ do not intend, 
however, to limit the invention to that specific: 
arrangement, of clients. The illustrated two clients 210 

10 and 22.0. can be implemented on a singler computer platf orm, 
as mentioned in^ an earlier section,, sor tiiat the reply 
entry manager 211. and log display processor 221 may reside^ 
in. the same client, computer . 

The\ above-described processing mechanisms of the 

15 present- invention ar& actually implemented on a computer 
system with> a^ set. of computer programs. Encoded^ in- those 
computer programs- are the functions of the inquiry handler 
120.,. reply entry manager 211,. and log display processor 
221. The: computer: system, executes^ such programs^ to^ provide 

20 tiie intendeds functions of: the? present, inventionv.. FOr the> 
purpose off storage^ and distribution.,, the; programs are^ 
stored^ in a computer-readable:^ storage^ medium. Suitable^ 
computer-readable storage' media include magnetic: storage 
media., optical, discs, magneto-optical storage media., and 

25 solid state: memory devices. Magnetic storage media include^ 
hard disk drives (HDD) , flexible disks (FD) , and magnetic 
tapes. Optical discs include digital versatile discs (DVD) , 
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DVD -RAM ^ compact: disc: read-only memorY (CD-ROM) , CD- 
Recordable (CD-R) , and CD-Rewritable (CD-RW). . Magneto- 
optical storage media include magneto -optical discs (MO). . 
Portable^ storage: media, such as DVD and CD-ROM, are used 
5 to distribute program products. Network -based: distribution 
of software- programs hasr also become popular,, in. which, 
master program files stored in a server computer are 
downloaded to user computers via a network- 
Each user computer stores necessary programs in 

10 its: local storage^ unit,. which have previously been 
installed from a portable^ storage media or downloaded f rom* 
a server computer.. The: user computer performs^ intended 
functions by executing the^ programs^ read, out of the: local 
storage^ unit. As an. alternative way of program: execution, 

15 thei computer may execute programs, reading, out; program, 
files directly from a portable storage medium. Another 
alternativet metilod is: that the^ user computer dynamically 
downloads^ programs^ from, a server computer when they arer 
demandedi and: executes; them, upon delivery . 

20 T<D summarize^ izh& above discussion;, the^ present: 

inventionv provid(es> a^ processr of storing log: records; of 
inquiries; and their corresponding replies? and- delivering 
them:^ upon request f rom a client, so that the operator will 
be able to: browse^ past, inquiries and replies^ on his/her 

25 client, console. Using those records: as examples, the: 
operator can answer the current inquiries, with reduced 
possibilities of making; a. mistake . 
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The foregoing ±s considered as lllus'tra'blve- oniy 
of the principles of the present invention. Further, since^ 
ntunerous modifications and changes will readily occur* to 
those skilled in the art, it is- not desired to limit the 
invention, to ^e exact construction and applications? shown* 
and described,, and accordingly, all suitable modifications- 
and ec[uivalents: xaay be regarded as falling within Ule: 
scope: of -Uie: invention in the^ appended claims and. tiieir 
equivalents: . 
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